1. Field of the Invention
The present invention relates to scan cells that are used to test a digital integrated circuit (IC) and in particular to using DFT-aware design planning information to optimize top-level scan wires and scan feedthroughs during design planning and then automatically update block-level and top-level scan chain information.
2. Related Art
In general, both logical and physical design tools can be used to create a physical design for an IC. Logical tools can determine the logic necessary to implement the desired functionalities of the IC. Physical design tools can place that logic on the IC in a manner that optimizes chip area and performance. Logical tools are only aware of logical hierarchy. Current physical design tools are aware of logical hierarchy and physical hierarchy. Both the logical and physical design tools use significant resources (e.g. memory and CPU time).
One way to reduce the resources used by the physical design tools is to take advantage of physical hierarchy, i.e. the arrangement of blocks, macros (i.e. design entities for which the physical design is already complete and the existing physical geometries are not modified), etc. on the chip. For example, it is well known that a logical block, once designed, can be used multiple times in a device. Using physical hierarchy, that block can then be copied and pasted over the chip as needed. Physical hierarchy also allows design work to be split up between multiple engineers (or engineering groups). That is, after a design is divided up into different functional areas, engineers can work on their respective blocks. Physical hierarchy also tries to minimize connections between the multiple blocks to optimize design characteristics, such as routability, timing, area, and power. Thus, physical hierarchy can be used to optimize time and resources.
FIG. 1 illustrates a conventional design planning and physical design technique 100 for creating a physical design (wherein this physical design can then be used to make a mask for the IC). In technique 100, the term “plan group” refers to an intended physical partition on the chip that includes a group of design elements. After design planning is complete, each plan group is formally designated a “block”. Thus, in reference to FIG. 1 and any associated conventional art, the terms “plan group” and “block” can be used interchangeably. Note that a chip design typically includes hundreds of blocks, wherein each block includes various combinational and sequential logic elements.
In step 101, the plan groups/blocks can be created. In step 102, any standard cells (e.g. less complex elements) and any macro cells (e.g. more complex elements) can be placed in a two-dimensional area representing the IC. In step 103, the plan groups can be shaped and placed in the same 2D area. For example, FIG. 2 illustrates an exemplary IC layout 200 that includes multiple plan groups 201 placed among macros 202 (e.g. memory or analog blocks).
Referring back to FIG. 1, in step 104, the power network for the plan groups and macros can be created. In step 105, the drivers that drive long wires in the plan groups and macros can be checked for strength and swapped for stronger drivers, if necessary. Additionally, clocks for the blocks and macros can be planned at this point. In step 106, wires connecting the design components are routed along approximated paths (“global route”). Next, the pin assignments at the edges of the plan groups (to connect the plan groups to other plan groups, macros, and/or pads of the IC) and any feedthroughs can be created. A feedthrough is a wire that traverses a plan group solely to provide communication between two other floorplan entities (e.g. plan groups, macros, pads, etc). For example, FIG. 3 illustrates a feedthrough 304 that traverses a plan group 302 to connect elements in plan groups 301 and 303, thereby facilitating their communication.
In step 107, the plan group level timing constraint files can be generated (i.e. an allocation of maximum time for each plan group based on the context of all placed plan groups).
Because the design of integrated circuits (ICs) is becoming increasingly complex, it is highly desirable to include testability in all stages of the design process. To facilitate testing of an actual IC, scan cells can be added at the block- and top-level. For example, FIG. 4A illustrates an exemplary block 400 that can include various interconnected combinational logic 401 and sequential elements (e.g. flip-flops or latches) 402. FIG. 4B illustrates block 400 as modified to include scan cells. Specifically, a plurality of logical multiplexers 410 have been provided, wherein a scan enable signal on wire 412 (only one shown for simplicity) can control which of its two inputs is selected as an output. Each multiplexer 410 can provide its output to an input terminal of a sequential element 402. A logical multiplexer 410 and its corresponding sequential element 402 can form a scan cell.
Note that in other embodiments, a scan cell can include multiple sequential logic elements. Further note that in other embodiments, scan cells can include components providing the equivalent to logical multiplexers 410 and sequential elements 402. For example, in one embodiment, scan cells can include sequential elements having a functional clock as well as a test clock (and no scan-enable). Thus, the use of scan cells including logical multiplexers is illustrative only and not limiting to the discussion herein.
One input terminal of logical multiplexer 410 can receive the input that would otherwise be provided to the input terminal of the sequential 402. The other input terminal of each multiplexer 410 can be connected to a wire 411 (shown as a dotted wire for convenience) that can facilitate forming a chain of only sequential elements 402 (and allow bypassing any combinational logic 401). This configuration allows test values to be quickly loaded into sequential elements 402. After loading the test values, then inputs from the other input terminals of multiplexers 410 can be selected (using scan enable wire 412). At this point, the test values can be applied to combinational logic 401 and then clocked to a scan output for analysis.
Notably, after chip testing is complete, multiplexers 410 and wires 411 are not needed for the functionality of the chip. Therefore, although scan cells are necessary to provide chip testability, their presence on the chip is otherwise a liability. For example, wires 411 can significantly contribute to congestion on the chip. In general, the order of the scan cells in the shift path can be changed with no impact on the test quality. However, current tool sets cannot take advantage of this flexibility, as explained below.
FIG. 5 illustrates an exemplary chip design tool set 500 including a logical synthesis tool 502, a design planning tool 505, and a physical design tool 506. Logical synthesis tool 502 can generate a netlist (i.e. a comprehensive listing of all components in the design and their interconnection), inserts scan chains (i.e. scan cells and their interconnections) into the netlist, and then outputs a design-for-test (DFT)-inserted netlist (i.e. the netlist with inserted scan chains) 503 and SCANDEF (i.e. the SCANCHAINS section of the DEF format used by the industry) data 504 (i.e. a first set of scan data for all blocks and a second set of scan data at the top-level) 504. Because logical synthesis tool 502 is unaware of any physical hierarchy this tool can be characterized as a logical hierarchy tool. Design planning tool 505 receives DFT-inserted netlist 503 and SCANDEF 504 to perform scan cell reordering, if desired, and output an updated DFT-inserted netlist 506 to physical design tool 507.
Note that the use of the term “tool” may or may not refer to a single executable. For example, tools 502, 505, and 507 could each include a set of commands forming a single executable used by a computer. In other embodiments, tools 502, 505, and 507 could comprise two or more executables.
Physical design tool 507, which is a physical hierarchy tool, does not have the ability to distinguish scan cells from other components in DFT-inserted netlist 503. However, SCANDEF 504 can advantageously identify those scan cells for physical design tool 507. Therefore, physical design tool 507 can use updated DFT-inserted netlist 506 in combination with SCANDEF 504 to generate and output a physical design 508. At this point, physical design 508 can be converted into a mask design for fabrication.
Note that SCANDEF 504 only describes scan cells that can be reordered (described in data as FLOATING, for example) and any constraints on such reordering. Exemplary constraints can include clocks (described in data as PARTITION), clock edges, power domains, and/or voltages that limit reordering of certain scan cells. Other designated FLOATING scan cells can be constrained to be in a certain order (described in data as ORDERED). DFT-inserted netlist 503, although not able to specifically identify scan cells, does include all scan cells.
For clarification, further note that from the perspective of a tester, a “scan chain” starts and ends at a chip pad. However, in one embodiment, that “scan chain” can include many scan chains that are sequentially connected, wherein these connected scan chains form a pad-to-pad path. Additionally, particularly in pad-limited designs, one internal connection point of a scan chain (i.e. a pin) may actually selectively connect to multiple scan chains (i.e. a fan-out), wherein at some point downstream, these multiple scan chains selectively connect to another internal connection point (i.e. a fan-in). For simplicity herein, a scan chain at the block-level starts and stops with pins, whereas a scan chain at the top-level starts and stops with pads. However, as noted above, this is merely illustrative and not limiting (e.g. a scan chain at the block-level could start with a pad and end with a pin; and a scan chain at the top-level could start and end with pins).
For example, FIG. 6 illustrates a scan chain 601 traversing two blocks 602 and 603 and including top-level scan cells V and U. Each of blocks 602 and 603 includes scan cells E, C, A, D, and B. FIG. 7A illustrates scan data 701 that describes either of blocks 602 and 603 as shown in FIG. 6. FIG. 7B illustrates top-level scan data 702 that includes blocks 602 (e.g. Block1) and 603 (e.g. Block2) as well as top-level scan cells V and U as shown in FIG. 6.
In the scan data of FIGS. 7A and 7B, FLOATING indicates that the designated scan cells (i.e. E, C, A, D, and B) in that block can be reordered. PARTITION indicates a constraint (in this case a clock (Clk) constraint), wherein if two blocks have the same PARTITION designator, then scan cells from the two blocks can be swapped. Further note that for the top-level scan data 702, the blocks simply indicate the number of scan cells (e.g. BITS 5)(rather than identifying individual scan cells), the input pins (e.g. IN test_s1), and the output pin (e.g. OUT test_sol).
Referring back to FIG. 5, assuming that design planning tool 505 changes the order of some scan cells, then SCANDEF 504 and updated DFT-inserted netlist 506 do not correspond. Notably, without such correspondence, physical design tool 507 may make many sub-optimal decisions. Alternatively, a user could manually modify SCANDEF 504 to reflect the modifications made by design planning tool 505. However, this alternative is not commercially viable (or perhaps not even physically possible in complex designs). In another alternative, the logic hierarchy can be changed in logic synthesis tool 502 to match the desired physical hierarchy. However, this alternative is tedious and prone to error, and thus is typically discouraged. Finally, and most probably, the user can opt to leave the physical hierarchy to be substantially similar to the logical hierarchy. That is, in effect, the updated DFT-inserted netlist 506 is ignored and DFT-inserted netlist 503 can instead be provided to physical design tool 507 (see dotted line). Unfortunately, this alternative can result in sub-optimal connections of the scan chains at the top-level of the physical hierarchy.
Therefore, a need arises for a design planning tool that can use DFT-aware design planning information to optimize top-level scan wires and can then automatically update block-level and top-level scan chain information.